With recent post on a forum regarding failure of SSD drive, someone suggested using the old-school "verify on" DOS command to let programs verify the bits can be read after each write, and saying the since SSD is fast, the performance lost should be barely noticeable.

I know that in DOS this command operates on BIOS, and with Win9X VXD virtual drivers gradually took over the functionality offered by them. But is there any information on what is the status of this command now? AFAIK Win8.1 CMD.EXE still have this command, but does this command affect only DOS programs, any process within that console session, the current logon user session, or the system? Or is the function of this command no longer work because we're using UEFI and the CMD never updated to revamp the code to use that?

If the command still works, is there registry setting somewhere for it to make the effect survives reboots?

Thanks you.

Hi cheong,

The VERIFY command now almost has the same purpose as the /V parameter in the COPY command; once set, you do not have to use the /V option while copying. After VERIFY has been set to ON, DOS checks for bad sectors following all data writes to disk while copying. This can cause a slowing copy operations. However, this verification process consists of confirming that the data just written can be read, no comparison of the source and destination data occurs. This command only applies to Microsoft MS-DOS platform, so I dont think it will affect any console or system session.

Regards

D. Wu

From my experience in the days of DOS, I remember VERIFY ON command slows down all writes, not limited to copy / xcopy command (that errata is probably what you're referring to. But read that carefully again. The errata just state what it do, what it don't do, and xcopy/copy with /v swtich behaves like VERIFY ON enabled, without declaring that VERIFY only affect these two commands). So I think this command actually alters BIOS behavior (or BIOS relays it) and affects all programs at the time of DOS.

AFAIK there is ATAPI command "set features" (EFh) subcommand "Enable Write-Read-Verify" (0BH) (command reference section 7.47.10). When set to mode 00H, it'll make the disk verify written location is readable after each write without additional burden to the system. That's why I think it's possible that it's still functional these days.

Btw, with NCQ on SATA III, I don't think there would be much hit to performance like it used to be on IDE days. And with media like SSD that 1) wears out after certain amount of write and 2) is very fast, it makes sense to have this kind of function enabled to me.

That's why I seek help for sometime that have access to source code to verify the command's current status for me.

• Edited by cheong00 4 hours 17 minutes ago

From my experience in the days of DOS, I remember VERIFY ON command slows down all writes, not limited to copy / xcopy command (that errata is probably what you're referring to. But read that carefully again. The errata just state what it do, what it don't do, and xcopy/copy with /v swtich behaves like VERIFY ON enabled, without declaring that VERIFY only affect these two commands). So I think this command actually alters BIOS behavior (or BIOS relays it) and affects all programs at the time of DOS.

AFAIK there is ATAPI command "set features" (EFh) subcommand "Enable Write-Read-Verify" (0BH) (command reference section 7.47.10). When set to mode 00H, it'll make the disk verify written location is readable after each write without additional burden to the system. That's why I think it's possible that it's still functional these days.

Btw, with NCQ on SATA III, I don't think there would be much hit to performance like it used to be on IDE days. And with media like SSD that 1) wears out after certain amount of write and 2) is very fast (Added on 2015/03/19: It doesn't use head to read data, so verify step can be done on controller concurrently without performance impact on the write), it makes sense to have this kind of function enabled to me.

That's why I seek help for sometime that have access to source code to verify the command's current status for me.

• Edited by cheong00 Thursday, March 19, 2015 6:44 AM

From my experience in the days of DOS, I remember VERIFY ON command slows down all writes, not limited to copy / xcopy command (that errata is probably what you're referring to. But read that carefully again. The errata just state what it do, what it don't do, and xcopy/copy with /v swtich behaves like VERIFY ON enabled, without declaring that VERIFY only affect these two commands). So I think this command actually alters BIOS behavior (or BIOS relays it) and affects all programs at the time of DOS.

AFAIK there is ATAPI command "set features" (EFh) subcommand "Enable Write-Read-Verify" (0BH) (command reference section 7.47.10). When set to mode 00H, it'll make the disk verify written location is readable after each write without additional burden to the system. That's why I think it's possible that it's still functional these days.

Btw, with NCQ on SATA III, I don't think there would be much hit to performance like it used to be on IDE days. And with media like SSD that 1) wears out after certain amount of write and 2) is very fast (Added on 2015/03/19: It doesn't use head to read data, so verify step can be done on controller concurrently without performance impact on the write), it makes sense to have this kind of function enabled to me.

That's why I seek help for sometime that have access to source code to verify the command's current status for me.

• Edited by cheong00 Thursday, March 19, 2015 6:44 AM

Hi

My apologies, I am supposing I did not make my point clearly.

Yes The VERIFY command was design to affect all write behavior of DOS, but since we insist that Windows Explorer will always copy with verify ON, the VERIFY command now almost has been used as the same purpose as the /V parameter in the COPY command.

I also think it's still functional these days

You could do a simple test for that since copying files can be up to twice as fast with verify OFF(I did that)

About the SSD with this command, your speculation make sense, but since no one did a test about this, there might be no convincing answer for now, and we do have limitation for this kind of test.

Regards

D. Wu

Ok. Thanks for the information. :)